home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Atari Compendium
/
The Atari Compendium (Toad Computers) (1994).iso
/
files
/
umich
/
telecomm
/
btst240l.lzh
/
READ240F.ST
< prev
next >
Wrap
Text File
|
1990-10-08
|
10KB
|
215 lines
Changes to 2.40f - 6th October 1990
-----------------------------------
1. Shell command does not convert the command to upper case any more. If
you want to change directory first then assuming you've got a good shell
installed such as craft, gulam or MSH then do something like:
Shell 1 cd c:\mydir; myprog
Or even better get it to call a batch file which changes the directory.
If you are using Pcommand then tough luck.
2. Screen blanking works properly. It sets color 0 to Black and clears the
screen. This should work in all resolutions.
3. Fixed problem with NoFullScreen bombing. Note that this error like many
of the others is also present in the PC version (though the PC doesn't
bomb with such error it just corrupts random memory!)
4. An additional configuration line has been added:
NoLineA
If this is present in BINKLEY.CFG then colours are set using the VT52
commands rather than the linea variables. This is slightly slower, but
should help it work better with software blitters such as Turbo-ST or
QuickST. The VT52 colour setting routine has been speeded up by only
sending the commands if the colour is different to the previous colours
used.
The linea variables are still used to find the cursor position and to
get information about the screen mode and size. The only alternative to
this that I can think of is to use the GEM VDI routines, which would
mean the program would have to be a PRG instead of a TTP, though I
can't see why that should cause any problems with anyone unless they
wanted to stick BT in their auto folder.
Colours are restored when exitting and displaying Help screens, etc.
When NoLineA is enabled then it just sets the colours to 0 and 15.
Without this the colours in use when BT was started up are used.
Previously you got whatever colours the last screen update happened to
have used.
5. Clear the keyboard buffer before all exits. Previously it only did this
when exitting with Control-X.
6. Tried to fix the timing problems. The basic problem is that when
sending characters to the RS232 port with TOS 1.4 or higher or using
TurboCTS, then the 200Hz interrupt seems to have great difficulty
getting through. I tried lots of things out such as revectoring and
lowering interrupt level, but nothing really worked. Any suggestions are
more than welcome.
As a compromise solution I have added the option to allow the clock to
be updated from the IKBD clock occasionally as suggested by Jon Webb.
To enable this option add the line:
IKBDclock
into Binkley.Cfg. This is called quite often and if the IKBD clock and
GEMDOS clock differ by more than +/- 2 seconds then the GEMDOS clock is
updated. This may cause problems with TOS 1.4 and higher, because
GEMDOS also updates the IKBD clock, so your clock could gradually lose
time.
7. Fixed problem with log file [Alt-L] not working properly in terminal mode.
8. Changed Janus so that it skips the Transmit section until the output
buffer has been sent. This should give the receiver a bit more chance
to catch up, and should stop the locking problem when both ends are
sending and flow control breaks in. This is now an option selectable by
the "SlowJanus" configuiration line... see point 12.
9. RTS/CTS flow control is now optional. By default it is enabled but it
can be disabled using the configuration line:
NoCTS
in BINKLEY.CFG.
10. Disabled the 38400 baudrate option, which wasn't implemented anyway.
It may be possible in future versions to implement this baud rate by
changing timer divide rates and things, but the ST seems to struggle
enough at 19200.
11. The baud rate can now be locked at the lowest level "fossil" routine
using:
STlockBaud <value>
Usage is the same as documented for the "lockbaud" statement, i.e. if
the baud rate is above <value> then the baud rate will be locked to
the maximum rate as selected with the "baud" statement. Otherwise it
will use the CONNECT rate.
If <value> is omitted or it is 0, then baudrate locking is enabled at
all speeds.
The advantage of using this is that the errorlevel and the value
written into BBSBATCH.BAT or SPAWNBBS.BAT will be the rate reported
from the CONNECT message rather than actual DTE rate.
A problem is that in terminal mode the baudrate is still locked!
12. A lot of fiddling with Janus and RS232 buffered output routines. I did
find a major problem which caused it to lock up sometimes and it does
seem to work better now. However there is a fundamental flaw in the
ST's RS232 routines whereby characters seem to get lost when it is
simultaneously sending and receiving. The loss is greater at higher
baud rates. This still saves you time though since even if each side
goes down to 50% efficiency you are still gaining overall. I believe
the root cause is that interrupt routines can affect the RS232 queue
structures concurrently with the non-interrupt sections, and there are
no interlock flags or anything. The other problem at high baud rates
is that RS232 interrupts are taking a lot of processor time and the ROM
routines (and even CTSPatch) aren't particularly well optimised. The
best solution to this would be to write the equivalent of a "Fossil".
I added another configuration option:
SlowJanus
which prevents Janus from transmitting packets until the Tx buffer is
empty. This slows down Janus a little bit without apearing to give any
more reliability. However using this the RTS/CTS handshaking doesn't
come into play so often (if you have set the RS232 buffers wisely).
See point 8.
Regarding buffers, it is essential that the receive buffer is over 2059
bytes and there's no harm making it bigger or leaving it at its default
of 8K. Janus will never transmit a packet greater than 2K (+ headers
and CRC checksums). The transmit buffer can be whatever size you like,
a small size makes it respond quicker to errors, but may slow things
down. The buffer sizes are set using the TBUF and RBUF environment
variables.
13. I Put a flag around the routines that set/restore the RS232 buffers.
This should gurantee that buffers are always restored correctly upon
exit from the program.
Summary of new BINKLEY.CFG options
----------------------------------
NoCTS
Disables RTS/CTS flow control. Note that Xon/Xoff is used in some places
anyway.
NoLineA
Disables the use of LineA variables for colour changing. VT52 is used
instead. LineA variables are still used for finding the cursor location
and to determine the screen size during initialisation.
IKBDclock
Forces the time to be updated occasionally from the IKBD clock.
STLockBaud <rate>
Locks the baudrate to your maximum baud rate as defined with "baud"
whenever trying to change to a baudrate greater than <rate>. If the
rate parameter is omitted then the DTE speed will always be your maximum
baud rate. This differs from the "lockbaud" statement in that
BinkleyTerm itself knows nothing about the DTE speed and operates using
the CONNECT message's speed instead.
SlowJanus
This is really a debug option. It stops Janus from transmitting a new
packet until the Transmit buffer is completely empty. This doesn't
really help a lot other than slowing things down a little. However feel
free to try it out if you are having Janus problems.
I've left the symbol table on this, so anyone using MONST2 or some other
debugger can perhaps find information about where it crashes, etc.
Known problems
--------------
The ST's RS232 routines just can not handle simultaneous transmit and
receive properly. The problem gets worse at higher baud rates.
HST mode